%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
% Self evaluation
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%


\section{Self evaluation}
After validating the design by creating overviews and documenting the scenarios with sequence diagrams we identified some shortcomings. This is a discussion about some parts of the system that could have been designed better. Note that this is not an exhaustive discussion; other improvements are always possible.



\subsection{Login Module}
In iteration 6 we fulfilled the requirements UC1: "Log in" and UC2: "Log off" with respect to the customer by introducing the \emph{Login Module}. In iteration 7 we fulfilled the same requirements but with respect to the employee by reusing the same component. This required no additional elements, but it turns out that it does create some unnecessarily high coupling between unrelated parts of the system.

We recognize that using the same component twice would be an improvement. The user account system for the customers can exist completely separated from the employee user account system.



\subsection{Cash Module}
In iteration 8 we abstracted the common banking functionality of \emph{ATM System} and \emph{SAB Online} by introducing the \emph{SAB App Functionality} microkernel. This left \emph{ATM System} with a \emph{replyTransaction} interface required to receive the confirmations for cash withdrawals and deposits. Together with the \emph{Employee Web App} component introduced in iteration 7, this fulfills the requirements UC7: "Deposit cash" and UC8: "Withdraw cash".

We recognize that these requirements could have been met in a more idiomatic and uniform way by introducing a common \emph{Cash Module} used by the \emph{ATM System} and the \emph{Employee Web App}.



\subsection{Transaction Processing System}
Losing a transaction command because of a system crash in the \emph{Transaction Processing System} is undesirable, even though it is not a quality requirement and won't cause fatal problems (no money is ever created or destroyed, not even with interbank transactions which can be rolled back). Additionally, storing delayed direct credits in the \emph{Transaction Scheduler} for long times doesn't seem realistic.

We recognize that these problems can be overcome by storing all not yet executed transaction commands in a database - possibly the \emph{Transaction Database} which also provides additional backup functionality. 
